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TITLE OF THE INVENTION 

MESSAGE CONVERSION SERVER AND IP TELEPHONE 

BACKGROUND OF THE INVENTION 
5 [Field of the Invention] 

The present invention relates to a calling method^usefl 
when a caller makes a call to a callee in a one-to-one 
communication mode on the Internet. * 

A 

Non-patent documents listed below are ref erred^in the fyM*ru^ 
10 description (In a following paragraph?) % 

[Non-patent document 1] 

IETF RFC3261 

[Non-patent document 2] 

IETF RFC2327 
15 [Non-patent document 3] 

IETF RFC1889 a f\ t 

In recent years, j^a tendency to integrate 
exchange-based telephone communications networks into IP 
networks (has been developed r witfi^a rapid advance in IP 

20 network technology. Telephone communications carriers have 
a plan to transfer data under voice (hereafter, simply 
referred to as DUV) on their own IP networks through Voice 
over IP (hereafter, simply referred to as VoIP) . VoIP 
consists of two protocols, one ^controlling call signaling 

25 and sessions and the other^ controlling DUV transfer. The 
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10 



20 



Internet Engineering Task Force (hereafter, simply referred 



to 



as IETF) [made aUspecif ications of i Session Initiation . 



Protocol (hereafter, simply referred to as SIP), IETF 

r 

RFC3261, defining (thej^method for call signaling and 
sessions. For example^ Session Description Protocol (SDP) t J\s~> 
IETF RFC2327, is applicable to the description of a session^ 
including an agreement on a codec and transfer rate to be 
internally used in SIP. 

Although no specific DUV protocol is defined in SIP, ^ 
Real-time Transport Protocol (RTP) ,^RFC1889, is commonly 
used. 

According to IETF RFC3261, SIP is[sucfi)a protocol (thaE)/^ 
a SIP messagejconsisting of a SIP Start Line, a SIP message 
header, and a SIP message body^is sent/received between two 
15 calling parties via a SIP server to^make an) agreement^boufj^ 
the call signaling mode on the callee side, the voice, jimage 
protocol and^bit rate to be used during conversation. 
Generally, the SIP Start Line describes the behavior of the 



25 



message originator, the SIP message header describes the 
telephone number of a callee, the SIP serverji passed, and 
Call-ID (call origination administration number) , and the 
SIP message body describes the proposed voice, image 
protocol, and bit rate to be used during conversation. 

Now, a procedure (ls)^described^(in brief] ranging from 
the start tojyend of a two-party conversation throughASIP^ 
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described in IETF RFC3261.and the problems^with^the 



procedure^(are) explained. 




conversation* throughiSIP . 





two-party conversation through^SIP. 



In Fig. 1, UserA, who belongs to a domain 3-1 and has 
an IP Telephone 2-1, makes a call to UserB, who belongs to 
a domain 3-3 and has an IP Telephone 2-2ivia SIP servers 1-1 



message for UserB to the SIP server Al-1 to establish a call 
with UserB (11) . The SIP server Al-1, when receiving the 
INVITE message, adds a VIA header to its message header and 
15 transfers the SIP message to the SIP server Bl-2. At that 
time, it also sends the SIP message containing a Start Line 
lOOTrying to the IP Telephone 2-1, which is the callee 
(destination) of the message (12) . The SIP servers Bl-2 and 
CI -3, when receiving the SIP message, take the same actions 
. 20 and transfer the message to the UserB 's IP Telephone 2-2. 

The IP Telephone 2-2, when receiving the SIP message, 
sends a Start Line 180Ringing and a SIP message for UserA 
to the SIP server CI -3 (13) to sound a ringing tone on the 
UserB side. The SIP message containing a Start Line 



10 



to 1-3. 



I 

First, UserA sends a Start Line INVITE and a SIP 

A 
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180Ringing terminates at the IP Telephone 2-1 via the SIP 

server. ^ 

The IP Telephone 2-2, when UserB picks up |a)j telephone 

receiver, sends a Start Line 200OK and a SIP message for 

5 UserA (14) , which in turn, terminates at the IP Telephone 

2-1 via the SIP server. The IP Telephone 2-1 sencjsback an 

A 

acknowledge (ACK) signal in response to the message (15)jandj 
when the ACK is received, a voice packet passes through a 
main signal path, enabling the two parties to initiate a 

10 conversation between them (16) . 

At the end of the conversation, UserA' s IP Telephone 
2-1 sends a Start Line BYE and a SIP message for UserB (17) , 
which in turn, (determines)^ t the IP Telephone 2-2 via the 
SIP server. In response to the message, the IP Telephone 

15 2-2 sends back the ACK to the IP Telephone 2-1 via the SIP 
server (18) . When the ACK is received, the conversation 
ends . 

SIP is a protocol for sending and receiving SIP 

messages between a caller and a callee. A UserlD and its 

II u 

20 DomainID are described in the headers, From specifying the 
caller contained in the message header, To specifying the 
callee, and Via specifying the SIP servers jjpassed (proxy 
mode)j because (these^nf ormation can be delivered as^hey arej^ 
when the callee sends it back. To establish a session with 
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the callee through SIP, the caller describes the IP address 
of his/her own terminal or^assigned DomainID in the headers. 

With regard to VoIP, a protocol which informs the 
callee of no UserlD (e.g. telephone number or UserlD) of the 

5 caller, (such) a mode has been proposed in IETF RFC3261 

the caller terminal creates a random UserlD, registers the 
random UserlD and the IP address of the terminal in the SIP 
server, and originates a call with the random UserlD 
designated as the caller. Through this protocol, the whole 

10 procedure for making a Caller Anonymous Call is performed 
on the caller side. 

If the IETF- supported communication mode, in which 
the caller makes a Caller Anonymous Call with his/her UserlD 
concealed, is used in the SIP system, only the random UserlD 

15 is registered in the SIP server. For this reason, the caller 
would a Caller Anonymous Call not only to the callee^ 

but also^the SIP server at the same time. The SIP server 
is difficult to control N andimanage calls because it cannot 
guess the real UserlD from the UserlD registered in it. In 

20 the IP telephone services provided by communications 
carriers and others, user management is required, for 
example, caller identification, service permission/denial 
determination, and talk time management. 

If a malicious third party intercepts a SIP message, 

25 he/she can (knowjjthe caller, the caller's SIP-URL, and the 
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assigned DomainID ^described in the SIP message, causing 



^ (damages} such as nuisance calls 



In addition, if the malicious third party knows the 
IP address of the IP Telephone, he/she can transfer a vast 
amount of packets to the IP Telephone after the end of 
conversation, making an attack, for example, DOS (Denial of 
Service) A disturbing processing on>|equipment at a high 
possibility. 



10 SUMMARY OF THE INVENTION 

An object of the present invention is to provide a 
methodJ^'Non caller informed call", which enables the SIP 
servers to manage caller information (UserlD identifying 
the UserlD of the caller sending the SIP message and his/her 

15 DomainID) jwhile concealing the information from the callee 

r ^ 

and [thermal icious third party. 

Another object of the present invention is to make it 

\ 

difficult for fthe\\ third pai;ty to identify the IP address 

assigned to the IP Telephone^ to minimize any j3amagejjcause|| 

20 when he| know* the IP address. 

A 

According to one aspect of the present invention, a 
packet forwarding devicejTJ transmits a message sent by a 
caller to a specified callee, wherein the device has a 
processing part for providing at least either (the)jlf unction 

r ^ 

25 for converting or (the)nf unction for erasing at least part of 
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the message sent by the caller upon his/her request and a 
control part for determining whether at least^he part of 
the message should be converted or erased^ and j converts or 
erases at least {th^ part of the message based on the 

5 determination in the control part. This mechanism enables 
information identifying the caller to be concealed from the 
callee. , 

At least the part of the message^converted or erased^ 
as described above * may be one of or any combination of: 

10 (1) [the^part identifying the user on a calling side in the 

SIP message header on an IP packet payload containing the 

messagef,!; 
\ 

(2) jy|th^ part identifying the caller's domain in the SIP 
message header on the IP packet payload containing the 

15 messageJTjj 

(3) l[)the) part of a Via tag in the SIP message header on the 
IP packet payload containing the messag^Jj 

(4) (th^ipart indicating the Call -ID domain in the SIP message 
header on the IP packet payload containing the message£]jand 

20 (5) (the^part identifying a UserlD in the SIP message body 
on the IP packed payload containing the message. 

It may be possible (tha§ A the control partjanalyzety the 
content of the message, when receiving itQ'anddf any given 
character string or header is detected, the processing party\ 

25 convert! or erase part of the message. Any given character 
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string is a series of numeric characters contained in the 
position of the first numeric string, for example "184" . Any 
given header is the SIP messag^hjaderjand^when its extended 
header is detected, the abovej processing part may convert 

5 or erase part of the message. , v i 

Additionally, it is preferable (tha^ja table, in which 
the correspondence between the contents of part of the 
message before and after conversion is containec^T isj 
(preparedj. According to one aspect of the present invention, 

10 to conceal information on SI^URL and the assigned domain 
of the caller, the SIP server; installed at a relay point 
between the caller and the callee converts the SIP message. 
The SIP server with the message conversion function is 
characterizedjthat it provides jth^jmethod for converting or 

15 erasing part of the message originated by the caller, (th^j^ 
processing part for determining whether it should be 
converted or erased or not, (the)^processing part for 
determining information to be used in conversion, and(the]^ 
table containing the rule of conversion. . 

20 According to jthej^aspect of the present invention, j^to 

make it difficult f or {the^third party tOj(know}the IP address 
of a caller's IP Telephone, the IP Telephone creates or 
obtains a temporary IP address to be used only once when the 
SIP message is sent and discards it as soon as the 

25 conversation ends Juj^. The IP Telephone is characterized in 
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that it provides (the^ method for creating or obtaining the 
IP address in conjunction with the origination of the SIP 
message andjdiscarding it as soon as the conversation ends, 

(the^processing part for registering the temporary IP address 

<\ 

5 in the SIP server, jthe^processing part for canceling its 

°\ 

registration from the SIP server, and (thijfc processing part 

for creating a random interface ID. 

It is possible thatj optionally , the step So^^j 

converting the SIP message using the SIP server and/or the 

10 step ^foi^obtaining the temporary IP address using the IP 

Telephone may be used. According to another aspect of the 

present invention, the SIP telephone communication method 

erf ^ , 

involves a step (Eo^ftreceiving [thej^SIP message, a step^or)^] 

checking the SIP message for any request for Anonymous Call, 

a step [fo^jexecuting at least one of two operations ,^ A ^ M ^ A ^ 

modification and deletion on at least part of the SIP message 

if any request is detected, and a step jfoi^ sending the SIP 

messageiprocessed as described above. It is preferable that* 

if the request for Anonymous Call is detected,^ modification 

20 is made on at least part of the SlP^and a table containing 

the correspondence between the contents before and after 

modification is created. 
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^^Lsecond (another} aspect of the present invention, the 
IP telephone communication method involves a process for 
25 modifying the caller address to [i t%temporary address at the 
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initiation of conversation, and (Ehe)|process for discarding 
the (above)temporary address at the end of conversation. 

^ third (anothe^ aspect of the present invention, the 
method for converting or erasing part of (th^jjmessage sent 
by the caller upon his/her request is characterized by a step 
(Bo^determining whether part of the message should be 
converted or erased, a step (fp^petermining information to 
be used in conversion^if it is determined to be modified, 



and a rule applicable to/ conversion. In addition, a 
telephone set is characterized in^it involves a^step (ioT}^°j 
modifying the address of a caller in conjunction with 
origination of the message every time he/she makes a call 
to prevent t^from being disclosed and a st^^o^^jdisposing 
the address indicating the different UserlDjused ati jjL~$*** j 
conversation as soon as the conversation ends£,}j and ^further 
provides (Eh^method for assigning the addresses indicating 
different UserlDs at^call origination and call receiving and 
fthe) A method for sending the user's call. The scope of the 
present invention includes the methods, devices, and 
20 systems described above. 

As explained above, the invention achieves jEhe)^ 
f unction^compatible with (thej^exchange -based Anonymous Call 
function in [the^IP Telephone. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schema tic^view) showing an exai^le^pf (the]*v 
SIP network (created f on explaining the object^ 6f| the present 
invention^; 

5 Fig. 2 is a sequence diagram showing an example of fthi)^ 

procedure for making a call in the SIP network ^cr eated tor} 
(explaining the object of the present invention!; 

Fig. 3 is a schema tic^drawingj showing^ the SIP network 
of the present invention; 
10 Fig. 4 is a flow chart showing the operational 

principle of (the^SIP server (witfi)jthe message exchange 
function of the present invention; (\ 

Fig. 5 is a block diagram of (theJjSIP server £lth|jthe 
message exchange function of the present invention; . 
15 Fig. 6 is a block diagram of (the^SIP server (with^ the 

message exchange function of the present invention; 

Fig. 7 is a^(vietf) showing the format of [th^IP packet 
containing jtheUSIP message; 

Fig. 8 is a schema tic^fview) showing an example of (the)j^ 
network using^[the) SIP server (wit^ (the message conversion 
function of the present invention. 

Fig. 9 is a sequencej(showing |th ^procedure for making 
a call in the example of the network using (thehSIP server 
(wi tfiymessage conversion function of the present invention; 
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Fig. 10 is a (view) showing the contents of a SIP message 
headerj unconverted andjconverted by (the^SIP server £tfithjjthe 
message conversion function of the present invention; 

Fig. 11 is a^iewjof the content of a SIP message body 
5 (SDP) ^unconverted by the SIP server with the message 
conversion function of the present invention; 

Fig. 12 is aifviewlof the content of a SIP message body 
(SDP)^ converted by the SIP server with the message 
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conversion function of the present invention; 

Fig. 13 is a^view^ showing^ the conversion table stored 
on the SIP server with the message conversion function of 
the present invention; * t *d hk>LJ 

Fig. 14 is^^another view} showing^ the conversion table 
stored on the SIP server with the message conversion 
15 function of the present invention; 

Fig. 15 is a schematic^Jviewj of {th% Network using (the)^ 
SIP server (witfi^the message conversion function of the 
present invention ; 

Fig. 16 is a sequence diagram showing the procedure 
20 for making a call in the network using the SIP server with 
the message conversion function of the present invention; 
Fig. 17 is aitview) showing the contents of the SIP 
j|ess^ge header/unconverted and^converted byfthe^SIP server 
jwitfi)j(the message conversion function of the present 
25 invention; 
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Fig. 18 is a^ie^^^wing the^conversion table stored 
on (thej^SIP server (witfi^the message conversion function of 
the present invention; A * * d , 

Fig. 19 is/another view) showing* the conversion table 
5 stored on (th^SIP server (witl^) the message conversion table 
of the present invention; l 

Fig, 2 0 is a schema tic^(view) showing (the)j(network using 
(th|)/SIP server (witi^)the message conversion function of the 
present invention ; 
10 Fig. 21 is a sequence diagram showing the procedure 

for making a call in the network using the SIP server /witfi^ 
the message conversion function of the present invention; 

Fig. 22 is ai(view\ showing the contents of the SIP 
mes sag^ unconverted and^converted by the SIP serve3j(witfi) the 
15 message conversion function of the present invention; 

Fig. 23 is a^(view) showing^the conversion table stored 
on jth^SIP server (witfij^the message conversion function of 
the present invention; A A rfrr±J 

Fig. 24 is^^nother viewj showing j| the conversion table 
20 stored on the SIP server (witti)j)the message conversion 
function of the present invention; 

Fi^g^^^ is a^(view) showing (thej^network using (th^>(SIP 
server (with)jthe message conversion function of the present 
invention; 
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Fig. 2 6 is a sequence^drawing) showing the procedure 
for making a call in the network using/(the) SIP server with 
the message conversion function of the present invention; 

Fig. 27 is a^^view) showincr the contents of the SIP 
5 message headeri unconverted and^converted by the SIP server 
with the message conversion function of the present 
invention; 

Fig. 28 is a flow chart showing the principle of (thej 
operation of the IP Telephone of the present invention^ 
10 ranging from the step (foo^jobtaining the temporary address 
to the step (fp^| discarding it; 

Fig. 29 is a block diagram showing the function of the 
IP Telephone of the present invention; 

Fig. 3 0 is a systematic diagram of IPv6 addresses; and 
15 Fig. 31 is a^(view) showing the content of (th^jSIP 

message header when a Caller Anonymous Call is made. 

DETAILED^ OF THE PREFERRED EMBODIMENTS 
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Embodiment 1 

Fig. 3 [is a view] showing a first embodin^n^ IP 

telephone line network using a SIP server (with ^message 

exchange function of the present invention.^? a 

/ ^[CS&h W 

^Fig. 4 is a flow chart (explaining an)^operational 

procedure of the SIP server 12-]^with the message exchange^ 

25 ^unctioi^. 



-15- 



f^/S Fig. 5 is ajblock diagram [explaining the function] of 
the SIP server (with the message exchange function] 12-1 . 

" " ( / JL (r Ji ijL^yv^wv _ ' 

v Fig. 6 is a ^iewjj^howing the hardware configuration 
of the SI P server(with the message exchange f unction^ 12 -1 . ^ 

^-Fig. 7 is a (^ie wis no wing an IP packet^ containing a SIP 
message, i The IP packet [is represented by\60,^an IPv4/v6 
headerfby) 61, a TCP/UDP header jb^ 62,^ a SIP Start Line^byJ 



64, a SIP message header [b^ 65, and a SIP message body (SDP) 
y| 66. 



10 Now, referring to Fig. 4 and Fig. 5^ the operational 

principle of the SIP server 12-1 (with the^message exchange 
function's) described (below}. j^^Jr 
First of all, The^IP packet indicated in Fig. 7j|via 
IF 51. Second, (receiving\jpf the SIP massage 22 is performed 

15 at a^message sending/receiving part 45j and/Start Line check 

f * I 

23,jHeader check 24, andjbody check 25 are performed[at a) 1 ^ 

SIP message checking part 44. If any error is detected in 

the SIP message, the process ends with j an error response 

notification 33 ^issue^. 

20 If no error is detected, thenjmessage conversion check 

26 is performed [a^message conversion request check 26 at 

a message conversion/processing part 47 . 

If no conversion request is detected, a Via header (In)^ 

A 

described in the SIP message header 64 at the v****-*-*^-. 
25 (exchange/processing part 47^and then the SIP message is sent 
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via IF51. If (thejjconversion request is issued with a flag 
561 and 571 (see Fig. 31) indicating thaqfthej "No caller 
informed call" is to be originated, the step (for converting 
(the^message header conversion 27 and the step(f oii^onverting 
the message body 28 are performed at the message 



conversion/processing part 47. These steps conceal 
information on the caller from {Cts)jcallee (destination) . 
After the conversion, a step^^or) extractits^k conver|$ft 
information 29 is performed at a converl^a information 

10 extraction/transfer part 46 to pick up header body 

information necessary for creating a conversion table. 
Then, a step {Eo^Lreating the conversion information table 
30 is performed at a conver^Sl entry creation/modification 
part 49, writing into the conversion information table 31 

15 is performed at a converil§8i entry I/O part 48, and the 
converted entry is registered at a converaSBfc entry 



registration part 50. The converted SIP message undergoes 
message transfer 32 at a SIP message sending/receiving part 
45 via IF51. 

20 According to the embodiment of the present invention, 

the functions of the conver%<A entry creation/processing 
A 

part 49 in the SIP message processing part 41 and the 
conversion^able processing part 42 shown in Fig. 5 (Is)j^f 
executed on^CPU7 2 shown in Fig. 6. The function of the 



25 



conver^lfik entry I/O part 48 shown in Fig. 5 is executed at 
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a conversion table fetching part 75 shown in Fig. 6. The 
function of the conversion tablej(registration)part 43 shown 
in Fig. 5 is executed at a conversion table storage part 74 
shown in Fig. 6 . 



Embodiment 2 If 

Now, a more detailed embodiment £s)^described (belo^. 



Fig. 8 is a schematic (viewj of^[a) network configuration 
[showing thejjsecond embodiment of the SIP server of the 
10 present invention.-^ 

r — — — r J 

L Fig. 9 is a sequence diagram (explaining!) the 
communication procedure (in the embodiment] of the network ^ 
(using the SIP server with the message conversion function) 
(of the present invention}. 
15 In the second embodiment, UserA makes a Caller 

Anonymous Call to UserB. The step jfo reprocessing the Non 
caller informed call is performed on the SIP server A12-2 
(with theWnessage exchange function. The step [f or^conver ting 
the SIP message is performed on the SIP server A (12-$) with 
20 a header conversion function used by the caller in sending 
the SIP message at the steps 111 and 112 in the sequence 
ranging from the start to the end of conversation's shown 
in Fig. 9. Note that the SIP server with the conversion 
function behaves as|showi^ inj^the first embodiment. Fig. 10, 
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Fig. 11, and Fig. 12 show the content of the converted SIP 
message in the second embodiment. 

Fig. 10 is a (view^showing the header part of the SIP 
message (65 in Fig. 7) . In the upper part, the unconverted 

5 header is shown^and^in the lower part, the converted header 
is shown. In the second embodiment, a UserlD 142 of the From 
tag and a part identifying the user of SIP-URL 143 in the 
unconverted header 141 are converted into, for example, 
character strings 147 and 148jsuch as Anonymous, from which 

10 the UserlD of the caller cannot be guessed. 

Fig . 11 is a jview^showing a body part of the SIP message 
(Unconverted) . The body part of the SIP message is 
represented by 66 in Fig. 7. 

Fig. 12 is a (viewtyshowing the body part of the SIP 

15 message (converted) . In this figure, the part identifying 
a UserlD 152 of the message body (SDP) 151^is converted into^ ' 
156. the part 153 ^identifying the user's address to be used 
during conversation in an "o","c" tag^is converted into the 
IP address^if described in FQDN (Fully Qualified DomainID) . 

20 As described above, the present invention enables 

information on the caller to be concealed by converting 
information on the caller, based on which the callee <^v 
identify the UserlD of the caller including the UserlD 142 
of the From tag, the part identifying the SIP-URL user 143, 
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and the part 152 identifying the UserlD of the message body 
(SDP) . fc 

Fig. 13 and Fig. 14 arej^views) showing the conversion 
tables stored on the SIP server 12 with the conversion 

5 function in the first embodiment of the present invention. 
These conversion tables include the table 170, which 
associates all the UserlDs converted into the same Call-ID 
172 with their real UserlDs 171 , the table 180, which 
associates anonymous UserlDs 181 previously stored on the 

10 SIP server as "Anonymousl-100" with their real UserlDs 182, 
and others. Reference to these tables associating anonymous 
UserlDs 181 with Call-ID 172 makesjsuccessful routing of the 
SIP messages. 



15 Embodiment 3 . 

Fig. 15 is a schematic^view) showing the network a 

configuration in(the^third embodiment of (the^SIP server jwitfi^ 

the message conversion function o^ ft the present invention. 

Unlike the embodiment shown in Fig. 8 ,j\anonymous processing 

C 

20 is executed on the SIP server $. 

^•Fig . 16 is a sequence diagram showing the procedure 
for processing conversation on the networkj^using the SIP/ 
jwith the message exchange function of the present inventior^. 
In (£he)jy third embodiment of the present invention, 
25 UserA makes a Callee Anonymous Call to UserB. The step^orj^j 
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converting the SIP message is performed on the SIP server 
C 

tk (12-3) with a header conversion function Ik, which sends 

^ 

the SIP message at the steps 211 and 212 in the sequence 
ranging from the start to the end of conversation^ as shown 

5 in Fig. 16. Note that the SIP server .with the conversion 
function behaves as^Qshown) in j^the first embodiment. 

Fig. 17 is a j^iew)j showing the content of the SIP 
message converted on the SIP server with the message 
conversion function. Both of the unconverted and converted 

10 message headers are shown (65 in Fig. 7) . 

In ^hd^j third embodiment of the present invention, the.. 
Via tag 222 is erased and only the Via tag 232 of (an ow^serverj 
is described in the unconverted message, header 221. The 
UserlD 223 in the From tag is converted intc^233, from which 

15 no UserlD of the callee can be guessed, such as Anonymous^ 
and the part 224 identifying SIP-URL is converted into^|22S), 
from which no UserlD and its domain can be guessed. In 
addition, the part 225 identifying the Call-ID' s domain is 
converted intoj\235. The rule of message body (SDP) 

20 conversion is the same as that of the first embodiment of 
the present invention. 

As described above, in the embodiment shown in Fig. 
17, the Via tag indicating the relay point for the message 
can be deleted to prevent the call source from being guessed. 

25 Alternately, the part 225 identifying the Call-ID' s domain 
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can be converted into temporary DomainID 235, from which no 
domain can be guessed. 

Fig. 18 and Fig. 19 are views showing the conversion 
tables stored on the SIP server 12-3 with the conversion 

5 function in the second embodiment of the present invention. 
These conversion tables include the table 27 1, which 
associates all the UserlDs converted into the same Call-ID 
273 with their real UserlDs 272, the table 281, which 
associates anonymous UserlDs 282 previously stored on the 

10 SIP server as "Anonymousl-100" with their real UserlDs 283, 
and others. The use of these tables in routing SIP messages 
conceals information from the callee, ensuring information 
security. 



15 Embodiment 4 

Fig. 20 is a view showing the network configuration 
of the SIP server in jthe^f ourth embodiment of the present 
invention . — -s 



20 



^Fig~ 21 is a sequence diagram showing the procedure 
for processing conversation in the networlu(using the SIP^ 
( ser ver with the message conversion functio^. 

In the fourth embodiment of the present invention, 
UserA makes a Caller Anonymous Call . The step {foi^bonverting 
the SIP message is performed on the SIP server A (12-4)^ with 
25 the header conversion function used by the caller in sending 
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the SIP message at the steps 311 and 314^and on the SIP server 
C (12-5)^ with the header conversion function at the steps 
312 and 313, which sends the SIP message to the callee in 
the sequence ranging from the start to the end of 
5 conversation's shown in Fig. 21. Note that the SIP server 
with the conversion function behaves as^(shownj in^the first 
embodiment . 

Fig. 22 is a (view)^ showing the content of the SIP 
message converted on the SIP, server with the message 

10 conversion function. In [thg jfourth embodiment of the 

present invention, first, the UserlDs 322 and 323 of the From 
tag in the unconverted header 321 (is)jlconverted into 
character strings 326 and 327, from which no UserlD of the 
callee can be guessedysuch as Anonymous^and the message body 

15 (SDP) is converted in accordance with the same rule as that 
of the first embodiment of the present invention. Second, 
the Via tag 332 in the unconverted header 331 is erased on 
the SIP server 12-5 and only the Via tag 33 6 of [an owg^ server ^ 
is described. The part 333 identifying SIP-URL in the From 

20 tag is converted into^337, from which no DomainID can be 
guessed. The part 334 identifying the Call-ID' s domain is 
converted intoyy33 8. 

Fig. 23 is a ^iew)^showing the conversion table stored 
on the SIP server 12-4 with the conversion function. 
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ig. 24 is a view showing the conversion table stored 
on the SIP server 12-5 with the conversion function. 

The conversion tables stored on the SIP server 12-4 
include the table 341, which associates all the UserlDs 
5 converted into the same Call -ID 343 with their real UserlDs 
342, the table 351, which associates anonymous UserlDs 352 
previously stored on the SIP server as "Anonymousl- 100" with 
their real UserlDs 353, and others. The conversion tables 
stored on the SIP server 12-5 include the table 361, which 
10 associates Call-ID 362 with DomainlDs 364, and others. 




Embodiment 5 

Fig. 25 is a schematics/view) showing the network 
structure in\th§ffifth embodiment of the SIP server of the 
15 prevent invention. -* — s 



^Fig. 26 is a sequence diagram showing the procedure 
for processing conversation in the network^ ^sing the Sip] 
fserver with the message conversion function of the present] 
(invention}. 

20 In the fifth embodiment of the present invention, 

UserA make a Caller Anonymous Call to UserB. The step (f ° ]t ^ r f 

converting the SIP message is performed on the SIP server 
C 

£ (12-6) with a header conversion function belonging to the 
A 

top level domain for each communications carrier at the 
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steps 411 and 412 in the sequence ranging from the start to 
the end of conversation*, as shown in Fig. 26. 



message converted on the SIP server with the message 
5 conversion function in the fifth embodiment of the present 
invention. In the fifth embodiment of the present 
invention, the Via tag 421 is erased and only the Via tag 



described in the unconverted message header 420 . The UserlD 
10 422 and the part 423 identifying user's SIP-URL in the From 
tag are converted into character strings 427 and 428, from 



Anonymous. In addition, the part 424 identifying the 
caller's domain in the Call-ID tag is converted into the top 

15 level domain 429 of the communication carrier. The rule of 
message body (SDP) conversion is the same as that of the 
first embodiment of the present invention. The conversion 
tables stored on the SIP server 12-6 with the conversion 
function in the fourth embodiment of the present invention 

20 are shown in Fig. 18 and Fig. 19jand the contents of these 
tables are the same in those of the second embodiment of the 
present invention . 



Fig. 27 is 




showing the content of the SIP 




communication carrier, is 



which no UserlD of the callee can be guessed, such as 



Embodiment 6 
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Fig. 28 is s flow chart |exp lain ingjj the operational 
principle of the IP Telephone using the temporary IP address 



at conversation, 



^Fig. 29 is a block diagram^(explaining) the function of 

5 the IP Telephone. The operational principle of the IP 

Telephone in the sixth embodiment of the present invention 

^Is^described below. 

^Fig . 30 is a ^systematic] diagram of IPv6 address es. 

^ Fig . 31 is a view showing the SIP message header used 

10 when a Caller Anonymous Call is made. 

First, the procedure for initiating a call (ls)w^^- 

described jbelov^. When the caller originates a call to 

another user, the IP Telephone 521 initiates the stepfforM 

sending the SIP message and executes the step (fo^ selecting JW 

15 address acquisition method 502. If a random address 

Sol J 

creation method is selected, then the step (f o^^sending 
Router Solicitation (503) is performed to obtain an IPv6 
address prefix 551 from a router in the same subnet. When 
the router sends Router Advertisement in response to Router 
20 Solicitation, a step^f o^teceiving Router Advertisement[505) 
is performed to obtain the address prefix 551. 

Second, a step (fp £)/[(: r eating an interface ID 506 is 
performed at the random interface ID creation part 528 to 
create an IPv6 interface ID552. 
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10 



15 



20 



es of the address prefix and the interface 

ID are represented by 553 and 554 in Fig. 30. 

Col $\ 

Third, a step ^forj/creating an IP address [5 077 is 
performed at a temporary IP address processing part 529 
using the address prefix 501 and the interface ID552. 



If the option of acquisition from the DHCP server is 

selected at the step (f oi)^selecting the address acquisition 

method [50^, a request for address acquisition 504 is issued 

to any address distribution server, for example, the DHCP 

server^ to execute a step ^or^'obtaining the temporary IP 

address 508.-*-^ 

^Whenever an IP call is made through IPv4, the address 

should be obtained from an external server.. 

Fourth, the modif ied^en^ry or new registration entry 

of user information is(crestedj i at a user data processing part 

532 using the temporary address and the UserlD to execute 

r n 

a step ^f ©reregistering the user's account [50 91. 

5~io H r 

Fifth, a stepjdpr) creating the SIP message plOj at a 
SIP message header creation part 531 and a step^or) creating 
the SIP message body (51 1] at a SIP message body creation part 
530 are performed, respectively. 

As shown in Fig. 31, if it is desired to making a call 
with the UserlD of the caller concealed from the callee, a 
flag indicating the SIP server (that^a Caller Anonymous Call 
25 is to be made is described in the SIP message header 560, 
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10 



for example, a numeric^l84 (561) attached to the position 
directly before the telephone number of callee in the case 
of making a Caller Anonymous Call at an exchange -based 
telephone system or extended header (571) . 

Then, the steps (f or^creating a SIP Start Line INVITE^ 
indicating a request to the calleej and creating the SIP 
message at a SIP signaling generation part 525) and the steps 
reating the IP packet 60 and sending the DIP signal 512 



at an IP packet processing part 526 are performed, 
respectively* to initiate conversation. 

J tni <\ 

At the end of the conversation, a step (f oi^ferasing the 
account registration entry(514)is performed at the user data 
processing part 532 \t^erase the account from the SIP server* 
and a step ^fo^discarding the IP address (515) is performed 
15 at the temporary IP address processing part 52 9, 
respectively, to complete the process. 

The procedure for receiving ^the SIP message is the 



same as that Jf or sending it^with (aii)j exception that the step 
^ofju'obtaining the temporary address and the step (for)^j 
20 registering the account are performed when the IP Telephone 
is powered onjor^when the IP Telephone logs in the domain 
managed by the SIP server, the SIP message is received, 
conversation is^(mad<i), the temporary IP address is discarded 
at the end of the conversation, and immediatel^(af ter then), 
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a new temporary IP address is obtained for account 
registration. a 

As (toowii^f rom the descriptionjabove, the IP Telephone 
has two temporary IP addresses, one for sending and one for 
5 receiving, while the IPv4 telephone set has eitheryjof them^ 
because two addresses cannot be set on one terminal at the 
same time. 

The callee receiving the SIP signal from the SIP 
server with header conversion function according to the 
10 embodiment of the present invention described above can 
recognize that the calle^fmakes) a Caller Anonymous Call by 



checking the converted UserlD indicatingjanj anonymous in the 
SIP message. 

If the DomainID in the SIP message has been converted 
15 or erased for concealing^f romjother, the callee receiving 
the _ SIP message cannot knowftj th e caller's domain. ? 

*(ThQ malicious third party .even when receiving the SIP 
message sent by the caller, (is^dif f icult to guess the caller 
because the UserlD is concealed. 
20 The callers can be managed by any organization, for 

example, a communications carrier^ because the SIP server 
contains the conversion tables associating (between^ real 
UserlDs (and)j[their other parameters. 

With the IP Telephone using^hejtemporary IP addresses 
25 according to the embodiment of the present invention, the 
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IP address is modified for each pall, yiaking^dif f icult [it] 
f or ^th^malicious third party to guess^the caller^even when 
he/she intercepts the IP packet during conversation. 

t In addition, when the SIP message is sent through 
IPv6, ^the third party (is difficult) to guess the^ caller 
because many IP addresses are described in the same segment. 



